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(54) Stub search loading system and method, server apparatus, client apparatus, and 
computer-readable recording medium 



(57) In a stub search loading system for, in execut- 
ing remote method invocation from a plurality of clients 
to a server, downloading a stub necessary in a request 
source client from the server, the request source client 
includes a stub search section, and the server includes 
a stub search interface. The stub search section sends 
a stub request formed from a stub name and client iden- 



tifier to the server and receives a stub returned from the 
server. In response to the stub request, the stub search 
interface returns to the request source client the stub 
appropriate for the runtime environment of the request 
source client on the basis of the designated stub name 
and client identifier. A stub search loading method, serv- 
er apparatus, client apparatus, and computer-readable 
recording medium are also disclosed. 
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Description 

[0001] The present invention relates to a computer 
system having a remote method invocation mechanism 
and, more particularly, to a stub search loading system 5 
and method in a computer system in which a stub nec- 
essary on the client side is downloaded from the server 
side and used. 

[0002] RMI (Remove Method Invocation) is a mecha- 
nism capable of invoking the method of a Java object 10 
on another Java virtual machine as if it were the method 
of an object on a given Java virtual machine and is used 
to built a distributed system using Java. 
[0003] Fig. 10 shows the outline of the RMI mecha- 
nism. The RMI is processed according to the following 15 
procedure. First, an invocation from a client object to a 
server object is sent to a stub placed in the client (S31). 
The stub executes marshaling or the like for this invo- 
cation and transfers it to a skeleton in the server (S32). 
The skeleton executes unmarshaling or the like for the 20 
invocation received from the stub to generate the invo- 
cation to the server object and invokes the server object 
(S33). Marshaling means processing of converting an 
internal data expression format into a data format ex- 
changeable between different systems, and unmarshal- 25 
ing means reverse processing. 
[0004] The server object executes the invoked meth- 
od and, if a return value is present, sends it to the skel- 
eton (S34). The skeleton executes marshaling orthe like 
for the received return value and returns it to the stub in 30 
the client (S35). The stub executes unmarshaling orthe 
like for the received return value and returns it to the 
invocation source client object as the return value of 
method invocation (S36). 

[0005] In this way, all invocations from a client object 35 
to a server object are done through a stub. That is, a 
stub serves as an agent for a server object on a client 
side in a distributed environment. Generally, one stub is 
necessary for each server object. 

[0006] A sub and skeleton can be generated by, using 40 
an IDL (Interface Definition Language) compiler, an IDL 
file in which a server application invocation interface is 
described. In actual use of a stub and skeleton, in com- 
piling a client application and server application, the stub 
and skeleton are generally linked and compiled together 45 
(this scheme will be referred to as a static scheme here- 
inafter). In the static scheme, however, information nec- 
essary to invoke a remote method must be determined 
not at the time of program execution but at the time of 
compiling. If a stub linked to a program does not match so 
a remote method invoked in executing the program, an 
error may occur, resulting in a decrease in efficiency. In 
addition, the storage capacity must be large enough to 
store all stubs on the client side. 

[0007] To solve this problem, a scheme in which a cli- 55 
ent dynamically downloads a stub from a server and us- 
es it has been proposed, as disclosed in Japanese Pat- 
ent Laid-Open No. 10-83308 (this scheme will be re- 
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ferred to as a dynamic scheme hereinafter). A conven- 
tional dynamic scheme will be described below with ref- 
erence to the accompanying drawings. 
[0008] Fig. 11 shows a conventional computer system 
that employs a dynamic scheme. In this conventional 
computer system.client computers 101 and 102, aserv- 
er computer 103, and a name server computer 104 are 
connected to each other through a network 105. 
[0009] A Java runtime environment 110 is built in the 
client computer 101. Classes 111 are executed under 
the Java runtime environment 110. A Java runtime en- 
vironment means software required to execute a Java 
program, including a Java virtual machine. Each class 

111 is a class file created by compiling a Java source 
code and is described using a code to be executed by 
a Java virtual machine. Referring to Fig. 11 , all classes 
in the client computer 101 , including stub classes, are 
expressed by the classes 111. 

[001 0] The Java runtime environment 1 1 0 includes a 
control section 112, a class loader 114 having a stub 
search section 113, and instances 1 1 5. The stub search 
section 113 downloads a stub class from the server 
computer 103. The class loader 114 loads to the Java 
runtime environment 110 the class 111 and the stub 
class downloaded by the stub search section 113. The 
instances 115 are objects obtained by converting the 
classes 1 1 1 and stub classes loaded by the class loader 
114 into instances. Referring to Fig. 11 , all instances in 
the Java runtime environment 110, including stub class 
instances, are expressed by the instances 115. 
[001 1 ] Each i nstance (object) 1 1 5 has a variable (sta- 
tus) and method (behavior). As is known, in object-ori- 
ented programming, such a plurality of objects (instanc- 
es) exchange messages, and a program is executed by 
the interaction between the objects. The control section 

112 is the control module of the Java runtime environ- 
ment 1 1 0 and includes a Java virtual machine. The con- 
trol section 1 1 2 generates the instance 1 1 5 by convert- 
ing each of the classes downloaded by the class loader 
114 into an instance and controls program execution on 
the client side. 

[0012] The other client computer 102 has the same 
arrangement as that of the client computer 1 01 . 
[0013] A Java runtime environment 120 is built in the 
server computer 1 03. Under the Java runtime environ- 
ment 120, classes 121 and skeleton classes 122 are ex- 
ecuted. The Java runtime environment 120 includes a 
control section 123, class loader 124, and instances 
1 25. The class loader 1 24 loads the class 121 and skel- 
eton class 122 to the Java runtime environment 120. 
The instances 125 are objects generated by converting 
the classes 1 21 and skeleton classes 1 22 loaded by the 
class loader 124 into instances. Referring to Fig. 11 , all 
instances in the Java runtime environment 120, includ- 
ing skeleton class instances, are expressed by the in- 
stances 125. 

[0014] The control section 123 is the control module 
of the Java runtime environment 120 and includes a 
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Java virtual machine. The control section 1 23 generates 
the instance 125 by converting each of the classes and 
skeleton classes loaded by the class loader 124 into an 
instance and controls program execution on the server 
side. 

[0015] The server computer 1 03 also has stub class- 
es 126 and stub search interface 127. The stub classes 
126 and skeleton classes 122 are in a one-to-one cor- 
respondence. That is, pairs of skeleton classes 122 and 
stub classes 126 generated by compiling IDL files are 
held and managed by the server computer 1 03. Each of 
these stub classes 126 can be searched for in accord- 
ance with the name of the stub class. Upon receiving a 
download request with a designated stub class name 
from the stub search section 113 in the client computer 

101 or 102, the stub search interface 127 searches for 
the stub class 126 having the designated stub class 
name and returns it to the stub search section 1 1 3 of the 
request source. 

[001 6] When the client computer 101 or 1 02 does not 
know the server computer 1 03 from which a necessary 
stub class should be downloaded, i.e., when the client 
computer 1 01 or 1 02 does not know the server computer 
103 which holds the necessary stub class, the name 
server computer 1 04 notifies the client computer 1 01 or 

1 02 of the corresponding server computer 1 03. Typical- 
ly, the name server computer 104 manages a table 
which holds, for each stub class name, the identifier of 
the server computer 1 03 that holds the stub class. Upon 
receiving an inquiry with a designated stub class name 
from the client computer 101 or 102, the name server 
computer 104 looks up the table and returns the identi- 
fier of the corresponding server computer 1 03. 
[0017] The RMl processing procedure in the conven- 
tional computer system will be described next with ref- 
erence to the flow chart shown in Fig. 12. 

[0018] When remote method invocation is done from 
the instance 1 1 5 of a certain class 1 1 1 to invoke a certain 
method of a certain class 121 in the server computer 
1 03, the control section 1 1 2 in the Java runtime environ- 
ment 1 1 0 of the client computer 1 01 determines whether 
the instance 1 1 5 of the stub class 1 26 to be used for the 
invocation is present in the Java runtime environment 

110 (S101). If YES in step S101, the remote method in- 
vocation is realized using the instance 115 of the stub 
class 126 in accordance with the procedure described 
with reference to Fig. 10 (S102). 

[001 9] If the instance 1 1 5 of the stub class 1 26 to be 
used forthe current invocation is not present in the Java 
runtime environment 110, the control section 1 1 2 deter- 
mines whether the stub class 1 26 to be used for the cur- 
rent invocation is present in the classes 1 1 1 in the client 
computer 101 (S103). If YES in step S103, the control 
section 1 1 2 causes the class loader 1 1 4 to load the class 

111 of the stub class to be used forthe current invocation 
to the Java runtime environment 1 1 0 (S1 04) and convert 
the class 111 into an instance, thereby generating the 
instance 115 of the stub class 126 to be used for the 



current invocation (S105). The remote method invoca- 
tion is realized using the instance 115 of the stub class 
126(S102). 

[0020] If the stub class 1 26 to be used for the current 
5 invocation is not present in the classes 111 , it is deter- 
mined whether the client computer 1 01 side knows the 
location of the stub class 126 to be used for the current 
invocation (S106). The location of the stub class 126 to 
be used for the current invocation can be included in, e. 
10 g., that invocation. Alternatively, the location of each 
stub class 1 26 can be managed by the class loader 1 1 4. 
In such case, the client computer 101 side knows the 
location of the stub class 126. 

[0021] On the other hand, if the client computer 101 
15 side does not know the location of the stub class 1 26 to 
be used for the current invocation, the control section 
112 designates the class name of the stub class and 
inquires the name server computer 1 04 about it (S1 07). 
In response to this inquiry, the name server computer 
20 104 notifies the client computer 101 of the location of 
the stub class having the designated class name 

(5108) . 

[0022] When the location of the stub class 126 to be 
used forthecurrent invocation is known, the control sec- 
25 tion 112 causes the stub search section 11 3 to designate 
the class name and request the stub class of the server 
computer 103 uniquely determined by the location 

(51 09) . The stub search interface 1 27 in the server com- 
puter 1 03 searches for the stub class having the desig- 

30 nated class name from the stub classes 1 26 and returns 
the stub class to the client computer 101 of the request 
source (S1 1 0 and S1 1 1 ). The returned stub class is load- 
ed to the Java runtime environment 110 by the class 
loader 1 1 4 (S1 04), and the instance of the stub class is 

35 generated by the control section 112 (S105). The re- 
mote method invocation is realized using the instance 
1 1 5 of the stub class 1 26 (S 1 02). 
[0023] If no corresponding stub class is found by 
search by the stub search interface 1 27, a message rep- 

40 resenting it is returned to the client computer 101 
(S11 2). In this case, the stub class download request on 
the client computer 1 01 side fails, and the remote meth- 
od invocation is ended as an error by exceptional 
processing. 

45 [0024] A stub class is the class of a stub class in- 
stance for executing marshaling or the like and has a 
structure depending on the stub class runtime environ- 
ment, which is specified by the machine, OS (Operating 
System), or Java runtime environment of the client com- 

50 puter where the stub class is to be executed. For this 
reason, if the type of the Java runtime environment 110 
where the stub classes are executed changes, stub 
classes on the client side, which are necessary to invoke 
the methods of the instances 125 to be executed under 

55 the Java runtime environment 1 20 of the server compu- 
ter 103, have different contents even when they have 
the same class name. 

[0025] In the conventional computer system de- 
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scribed with reference to Fig. 1 1 , the stub search section 
1 1 3 in the client computer 1 01 requests a stub class by 
designating a class name, and the stub search interface 
1 27 in the server computer 1 03 returns a stub class hav- 
ing the designated class name. This procedure poses 5 
no problem if the client computers 1 01 and 1 02 use the 
Java runtime environments 1 1 0 of the same type. How- 
ever, if the types of the Java runtime environments are 
different, only a client computer having a Java runtime 
environment adaptive to the stub class downloaded 
from the server computer 103 normally operates, 
though the normal operation cannot be guaranteed for 
the remaining client computers. 
[0026] This means that since the types of Java runt- 
ime environments are difference, the plurality of client 
computers 101 and 102 which cannot use the same stub 
class cannot execute remote method invocation for the 
same server computer 103 by acquiring a stub by the 
dynamic scheme. This also means that a plurality of 
server computers must be prepared to allow a plurality 
of client computers, which cannot use the same stub 
class because of the difference in the type of the Java 
runtime environment, to execute remote method invo- 
cation. 

[0027] It is an object of the present invention to pro- 
vide a stub search loading system and method, server 
apparatus, client apparatus, and computer-readable re- 
cording medium, which allow a plurality of client com- 
puters using different types of Java runtime environ- 
ments to download, from a single server computer, a 
stub class that can be used for remote method invoca- 
tion in each client computer. 

[0028] It is another object of the present invention to 
provide a stub search loading system and method, serv- 
er apparatus, client apparatus, and computer-readable 
recording medium, which can dynamically generate and 
download an appropriate stub class when a stub class 
requested by a client computer is not present in a server 
computer. 

[0029] In order to achieve the above objects, accord- 
ing to the present invention, there is provided a stub 
search loading system for, in executing remote method 
invocation from a plurality of clients to a server, down- 
loading a stub necessary in a request source client from 
the server, wherein the request source client comprises 
stub search means for sending a stub request formed 
from a stub name and client identifier to the server and 
receiving a stub returned from the server, and the server 
comprises a stub search interface for, in response to the 
stub request from the request source client, returning to 
the request source client the stub appropriate for a runt- 
ime environment of the request source client on the ba- 
sis of the designated stub name and client identifier. 



Brief Description of the Drawings 
[0030] 

Fig. 1 is a block diagram of a computer system ac- 
cording to the first embodiment of the present in- 
vention; 

Fig. 2 is a block diagram showing an arrangement 
for generating stub classes to be held in a server 
computer shown in Fig. 1 ; 

Fig. 3 is a block diagram showing another arrange- 
ment for generating stub classes to be held in the 
server computer shown in Fig. 1 ; 
Fig. 4 is a flow chart showing the RMI processing 
procedure in the computer system shown in Fig. 1 ; 
Fig. 5 is a block diagram of a computer system ac- 
cording to the second embodiment of the present 
invention; 

Fig. 6 is a block diagram of a stub generation sec- 
tion shown in Fig. 5; 

Fig. 7 is a flow chart showing the RMI processing 
procedure in the computer system shown in Fig. 5; 
Fig. 8 is a block diagram of a computer system ac- 
cording to the third embodiment of the present in- 
vention; 

Fig. 9 is a flow chart showing the RMI processing 
procedure in the computer system shown in Fig. 8; 
Fig. 10 is a view showing the outline of an RMI 
mechanism; 

Fig. 1 1 is a block diagram of a conventional compu- 
ter system; and 

Fig. 12 is a flow chart showing the RMI processing 
procedure in the conventional computer system. 

Description of the Preferred Embodiments 

[0031] The present invention will be described below 
in detail with reference to the accompanying drawings. 
[0032] Fig. 1 shows a computer system according to 
the first embodiment of the present invention. In the 
computer system of this embodiment, client computers 
1 to 3, a server computer4, and a name server computer 
5 are connected to each other through a network 6. The 
network 6 is an arbitrary network capable of digital data 
transmission/reception between computers, such as a 
LAN (Local Area Network), WAN (Wide Area Network), 
public switched telephone network, or Internet. The 
communication medium on the network can be either 
wired communication or wireless communication, or any 
other medium. 

[0033] A Java runtime environment (1) 10 is built in 
the client computer 1. Classes 11 are executed under 
the Java runtime environment 10. Each class 11 is a 
class file created by compiling a Java source code and 
is described using a code to be executed by a Java vir- 
tual machine. Referring to Fig. 1 , all classes in the client 
computer 1, including stub classes, are expressed by 
the classes 11, 
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[0034] The Java runtime environment 10 includes a 
control section 12, a class loader 14 having a stub 
search section 13, and instances 15. The stub search 
section 1 3 downloads a stub class from the server com- 
puter 4. The class loader 14 loads to the Java runtime 5 
environment 10 the class 11 and the stub class down- 
loaded by the stub search section 1 3. The instances 1 5 
are objects obtained by converting the classes 11 and 
stub classes loaded by the class loader 14 into instanc- 
es. Referring to Fig. 1 , all instances in the Java runtime 
environment 10, including stub class instances, are ex- 
pressed by the instances 15. 

[0035] The control section 1 2 is the control module of 
the Java runtime environment 10 and includes a Java 
virtual machine. The control section 12 generates the 
instance 15 by converting each of the classes down- 
loaded by the class loader 14 into an instance and con- 
trols program execution on the client side. 
[0036] The remaining client computers 2 and 3 have 
the same arrangement as that of the client computer 1 . 
However, since the client computers 1 , 2, and 3 use dif- 
ferent computer machines and OSs, the types of the 
built Java runtime environments are different. That is, in 
this embodiment, three, first to third Java runtime envi- 
ronments are present. The Java runtime environment 
(1) 10 is built in the client computer 1, a Java runtime 
environment (2) 1 6 is built in the client computer 2, and 
a Java runtime environment (3) 17 is built in the client 
computer 3. 

[0037] A Java runtime environment (1) 20 is built in 
the server computer 4. Under the Java runtime environ- 
ment 20, classes 21 and skeleton classes 22 are exe- 
cuted. The Java runtime environment (1) 20 includes a 
control section 23, class loader 24, and instances 25. 
The class loader 24 loads the class 21 and skeleton 
class 22 to the Java runtime environment (1) 20. The 
instances 25 are objects generated by converting the 
classes 21 and skeleton classes 22 loaded by the class 
loader 24 into instances. Referring to Fig. 1 , all instanc- 
es in the Java runtime environment (1) 20, including 
skeleton class instances, are expressed by the instanc- 
es 25. 

[0038] The control section 23 is the control module of 
the Java runtime environment (1) 20 and includes a 
Java virtual machine. The control section 23 generates 
the instance 25 by converting each of the classes and 
skeleton classes loaded by the class loader 24 into an 
instance and controls program execution on the server 
side. 

[0039] The server computer 4 also has a storage sec- 
tion 29 for stub classes 26-1 to 26-3, and a stub search 
interface 27 having a client identification section 28. The 
stub classes 26-1 form a set of stub classes which can 
be used in executing remote method invocation in the 
client computer 1 having the Java runtime environment 
(1). The stub classes 26-2 and 26-3 form sets of stub 
classes which can be used in executing remote method 
invocation in the client computers 2 and 3 having the 



Java runtime environments (2) and (3). 
[0040] Each stub class in the stub classes 26-1 to 
26-3 is held to be searched for in accordance with the 
name of the stub class. Stub classes in the stub classes 
26-1 to 26-3, which are to be used for the same remote 
method invocation, i.e., stub classes to be used to in- 
voke the method of the same server object in the server 
computer 4 have the same class name. 
[0041] Fig. 2 shows an arrangement for generating 
the stub classes 26-1 to 26-3 to be held in the server 
computer 4. Referring to Fig. 2, Java interface classes 
(classes each having only the information of the name 
and type of a method and no method mounting code) 
50-1 to 50-n define the interfaces of services provided 
by the server computer 4. Each of the Java interface 
classes 50-1 to 50-n is present for a corresponding serv- 
ice provided by the server computer 4. 
[0042] An RMI compiler 51-1 generates skeleton 
classes and stub classes for the Java runtime environ- 
ment (1) from the Java interface classes 50-1 to 50-n. 
The RMI compiler 51-1 compiles each of the interface 
classes 50-1 to 50-n, thereby generating the skeleton 
classes 22 and stub classes 26-1 to be held in the server 
computer 4 shown in Fig. 1 . 

[0043] An RMI compiler 51-2 generates skeleton 
classes and stub classes for the Java runtime environ- 
ment (2) from the Java interface classes. The RMI com- 
piler 51-2 compiles each of the interface classes 50-1 
to 50-n, thereby generating the stub classes 26-2 to be 
held in the server computer 4 shown in Fig. 1. Skeleton 
classes 52 that are simultaneously generated are not 
used. 

[0044] An RMI compiler 51-3 generates skeleton 
classes and stub classes for the Java runtime environ- 
ment (3) from the Java interface classes. The RMI com- 
piler 51-3 compiles each of the interface classes 50-1 
to 50-n, thereby generating the stub classes 26-3 to be 
held in the server computer 4 shown in Fig. 1 . Skeleton 
classes 53 that are simultaneously generated are not 
used. As each of the RMI (Remote Method Invocation) 
compilers 51-1 to 51-3, for example, an rmic can be 
used. 

[0045] In the arrangement shown in Fig. 2, one RMI 
compiler generates stub classes for one Java runtime 
environment. However, some RMI compilers can desig- 
nate the type of stub classes to be generated by a com- 
piler option. When such an RMI compiler is used, stub 
classes for a plurality of Java runtime environments can 
be generated by the single RMI compiler. 
[0046] For example, in an rmic, by designating a com- 
piler option, stubs and skeletons for the JRMP stub pro- 
tocol version 1 .1, stubs and skeletons for the JRMP stub 
protocol version 1 .2, or stubs and skeletons compatible 
with both the JRMP stub protocol versions 1 .1 and 1 .2 
can be generated. Fig. 3 shows an arrangement for gen- 
erating stub classes for a plurality of Java runtime envi- 
ronments using an RMI compiler 54 having such a func- 
tion. 
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[0047] Referring to Fig. 3, an option designation for 
the Java runtime environment (1) (e.g., a designation 
for generating stubs and skeletons compatible with both 
the JRMP stub protocol versions 1.1 and 1 .2) is given 
to the RMI compiler 54, and it is caused to compile each 
of the interface classes 50-1 to 50-n. With this process- 
ing, the skeleton classes 22 and stub classes 26-1 to be 
held in the server computer 4 shown in Fig. 1 are gen- 
erated. 

[0048] In addition, an option designation for the Java 
runtime environment (2) (e.g., a designation for gener- 
ating stubs and skeletons for the JRMP stub protocol 
version 1.1) is given to the RMI compiler 54, and it is 
caused to compile each of the interface classes 50-1 to 
50-n. With this processing, the stub classes 26-2 to be 
held in the server computer 4 shown in Fig. 1 are gen- 
erated. The skeleton classes 52 that are simultaneously 
generated are not used. 

[0049] Furthermore, an optional designation for the 
Java runtime environment (3) (e.g., a designation for 
generating stubs and skeletons for the JRMP stub pro- 
tocol version 1 .2) is given to the RMI compiler 54, and 
it is caused to compile each of the interface classes 50-1 
to 50-n. With this processing, the stub classes 26-3 to 
be held in the server computer 4 shown in Fig. 1 are 
generated. The skeleton classes 53 that are simultane- 
ously generated are not used. 

[0050] Referring back to Fig. 1 , upon receiving a stub 
request with a designated stub class name from one of 
the client computers 1 to 3, the client identification sec- 
tion 28 identifies a client identifier sent together and de- 
termines which set in the stub classes 26-1 to 26-3 
should be defined as a search target. The client identi- 
fication section 28 holds, e.g., a table 28a that holds the 
correlation between client identifiers and the names of 
sets of stub classes (the names of the stub classes 26-1 
to 26-3) and specifies a corresponding set of stub class- 
es by searching the table 28a using the client identifier. 
The stub search interface 27 searches for the stub class 
having the stub class name designated by the stub re- 
quest from one of the stub classes 26-1 to 26-3, which 
is determined by the client identification section 28, and 
returns the stub class to the client computer 1 , 2, or 3 
of the request source. 

[0051] In response to the inquiry with the designated 
stub class name from the client computer 1 , 2, or 3, the 
name server computer 5 looks up, e.g., a table 5a which 
holds and manages, for each stub class name, the lo- 
cation information of the stub class. With this process- 
ing, the location of the stub class is found and returned 
to the client computer 1 , 2, or 3 of the inquiry source. 
[0052] The RMI processing procedure in the compu- 
ter system shown in Fig. 1 , and mainly, stub class down- 
load operation as a characteristic feature of the present 
invention will be described next with reference to the 
flow chart shown in Fig. 4. 

[0053] For example, when remote method invocation 
is done from the instance 15 of a certain class 11 to in- 
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voke a certain method of a certain class 21 in the server 
computer 4, the control section 12 in the Java runtime 
environment 10 of the client computer 1 determines 
whether the instance of a stub class to be used for the 

5 invocation is present in the instances 1 5 of the Java runt- 
ime environment 10 (step S1). If YES in step S1, the 
remote method invocation is realized using the instance 
15 of that stub class in accordance with the procedure 
described with reference to Fig. 10 (step S2). 

10 [0054] If the instance 15 of the stub class to be used 
for the current invocation is not present in the Java runt- 
ime environment 10, the control section 12 determines 
whether the stub class to be used for the current invo- 
cation is present in the classes 1 1 in the client computer 

15 1 (step S3). If YES in step S3, the control section 12 
causes the class loader 14 to load the class 11 of the 
stub class to be used for the current invocation to the 
Java runtime environment 10 (step S4) and convert the 
class 11 into an instance, thereby generating the in- 

20 stance 15 of the stub class to be used for the current 
invocation (step S5). The remote method invocation is 
realized using the instance 15 of the stub class (step 
S2). 

[0055] If the stub class to be used for the current in- 

25 vocation is not present in the classes 11 in the client 
computer 1 , it is determined whether the client computer 
1 side knows the location of the stub class to be used 
for the current invocation (step S6). This determination 
processing is the same as in the prior art. If YES in step 

30 S6, the flow advances to step S9. If NO in step S6, the 
class name of the stub class is designated, and the 
name server computer 5 is inquired about it (step S7). 
In response to this inquiry, the name server computer 5 
notifies the client computer 1 of the location of the stub 

35 class having the designated class name (step S8). 
[0056] When the location of the stub class to be used 
for the current invocation is known, the control section 
12 causes the stub search section 13 to designate the 
class name and client identifier and request the stub 

40 class of the server computer 4 uniquely determined by 
the location (step S9). 

[0057] A client identifier is formed from the type or 
model of the client computer 1 , the type of the OS, the 
type of the Java runtime environment (1 ), the type of the 

45 control section 12, or a network address, or any other 
client information, or a combination of two or more of 
them. The client identifier may be information explicitly 
transmitted by the stub search section 13. The client 
identifier may be information such as a network address 

50 which is implicitly transmitted when a stub class request 
is transmitted and with which the client identification 
section 28 in the server computer 4 can identify the client 
computer. That is, the client identifier can be any infor- 
mation with which a runtime environment where a down- 

55 loaded stub is executed can be directly or indirectly 
specified. 

[0058] The stub search interface 27 in the server com- 
puter 4 determines, on the basis of the client identifier 
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received by the client identification section 28, which set 
in the stub classes 26-1 to 26-3 should be defined as a 
search target. The stub class having the stub class 
name designated by the stub request is searched for 
from the determined set of stub classes 26-1 , 26-2, or 
26-3 (step S1 0). In this case, the stub class is searched 
for from the stub classes 26-1 for the Java runtime en- 
vironment (1). 

[0059] If a corresponding stub class is present, it is 
returned to the client computer 1 of the request source 
(step S11). If no corresponding stub class is present, a 
notification representing that no corresponding stub 
class is held is sent to the client computer 1 (step S12). 
In this case, the stub class download request fails, ex- 
ceptional processing is executed in the client computer 
1, and, for example, the remote method invocation is 
ended as an error. 

[0060] Upon receiving the stub class from the server 
computer 4 as the request destination, the stub search 
section 13 in the client computer 1 transfers the stub 
class to the class loader 14. The class loader 14 loads 
the stub class to the Java runtime environment 1 0 (step 

54) . The control section 12 converts the loaded stub 
class into an instance to generate the instance 15 (step 

55) , and the remote method invocation is realized using 
the instance 15 (step S2). 

[0061] The operation has been described above by 
exemplifying the client computer 1. RMI processing in 
the remaining client computers 2 and 3 is also executed 
according to the same procedure as described above 
except that when a stub class request is sent from the 
client computer 2 or 3 to the server computer 4, the client 
identifier of the client computer 2 or 3 is sent. Hence, 
upon receiving a stub class request from the client com- 
puter 2, the stub search interface 27 in the server com- 
puter 4 searches for the stub classes 26-2 for the Java 
runtime environment (2). Upon receiving a stub class 
request from the client computer 3, the stub search in- 
terface 27 searches for the stub classes 26-3 for the 
Java runtime environment (3). 

[0062] According to this embodiment, stub classes 
that can be used for remote method invocation in the 
client computers 1 to 3 are downloaded from the single 
server computer 4 to the plurality of client computers 1 
to 3 having different types of Java runtime environ- 
ments. This makes it possible to execute remote method 
invocation forthe method of the same server object. For 
this reason, the server computer need to have only one 
service having the same inlet for the client computers 1 
to 3 with different configurations. 
[0063] The operation of this embodiment will be de- 
scribed next using a specific example. 
[0064] A client Foo on the client computer 1 executes 
remote method invocation for the server. When the stub 
class of BankServicelmpI class as a class having Bank- 
Service interface is necessary, the client computer 1 in- 
quires the name server computer 5 about the location 
of the stub class of BankServicelmpI. In response to this 



inquiry, http://japan/BankServicelmpl Stub.class is re- 
turned. 

[0065] The client computer 1 requests http://japan/ 
BankServicelmpI Stub.class of japan server using the 

5 HTTP protocol while adding a character string "User- 
Agent:Foo" as a client identifier to the HTTP header. The 
server computer 4 extracts http://japan/client/Foo/ 
BankServicelmpI Stub.class as a stub class that match- 
es the client identifier "Foo" and returns the stub class 

10 to the client computer 1 . 

[0066] When a client Bar on the client computer 2 ex- 
ecutes remote method invocation for the server, the 
name server computer is inquired. The procedure until 
http://japan/BankServicelmpl Stub.class is returned in 

15 response to this inquiry is the same as described above. 
Next, in requesting http://japan/BankServicelmpl Stub, 
class of japan server using the HTTP protocol, a char- 
acter string "User-Agent: Bar" as a client identifier is add- 
ed to the HTTP header. The server computer 4 extracts 

20 http://japan/client/Bar/BankServicelmpl Stub.class as a 
stub class that matches the client identifier "Bar" and 
returns the stub class to the client computer 2. 
[0067] The stub classes downloaded to the client 
computers 1 and 2 and converted into instances com- 

25 municate with the skeleton of BankServicelmpI of japan 
server to realize remote method invocation. 
[0068] Fig. 5 shows a computer system according to 
the second embodiment of the present invention. The 
same reference numerals as in Fig. 1 denote the same 

30 parts in Fig. 5. The second embodiment is different from 
the first embodiment in that a server computer 4 has a 
stub generation section 30 for generating a stub class 
for each of clients with different runtime environments. 
[0069] When an appropriate stub class to be returned 

35 to a client computer 1 , 2, or 3 that has requested the 
stub class is not present in stub classes 26-1 , 26-2, or 
26-3 in a storage section 29, a stub search interface 27 
sends a stub generation request with a designated stub 
class name and client identifier to the stub generation 

40 section 30. Upon receiving this request, the stub gener- 
ation section 30 dynamically generates a corresponding 
stub, and the stub search interface 27 returns the gen- 
erated stub to the client computer 1 , 2, or 3 of the request 
source. The newly generated stub class is also stored 

45 jn the storage section 29 to cope with a later stub re- 
quest, 

[0070] Fig. 6 shows the arrangement of the stub gen- 
eration section 30. Referring to Fig. 6, Java interface 
classes (classes each having only the information of the 

so name and type of a method and no method mounting 
code) 60-1 to 60-m define the interfaces of services pro- 
vided by the server computer 4. Each of the Java inter- 
face classes 60-1 to 60-m is presentfor a corresponding 
service provided by the server computer 4. Each of RMI 

55 compilers 61-1 to 61 -n is the same as that described 
with reference to Fig. 2 or 3 and generates skeleton 
classes and stub classes from the Java interface class- 
es. A control section 62 controls the respective sections 



7 



13 



EP1 202174 A2 



upon receiving a stub generation request with a desig- 
nated stub class name and client identifier from the stub 
search interface 27. 

[0071] The control section 62 manages, in an internal 
table 62a, correlation between each of the interface s 
classes 60-1 to 60-m and a stub class name. The control 
section 62 also determines a client identifier and man- 
ages, using, e.g., a correlation table (not shown) be- 
tween client identifiers and the RMI compilers 61-1 to 
61 -n, which of the plurality of RMI compilers 61 -1 to 61 -n 
should be used and which compiler option should be 
designated to generate a stub to be executed in the runt- 
ime environment of the client represented by the client 
identifier. 

[0072] The control section 62 inputs one of the inter- 
face classes 60-1 to 60-m, which is selected by the stub 
class name designated by the stub generation request 
from the stub search interface 27, to one of the RMI com- 
pilers 61 -1 to 61 -n, which is selected by the client iden- 
tifier designated by the stub generation request (also 
designates a compiler option as needed), thereby caus- 
ing the RMI compiler to compile the interface class. Of 
the skeleton class and stub class generated by the RMI 
compiler, the stub class is returned to the stub search 
interface 27 of the request source. 
[0073] When no corresponding interface class is 
present or when no corresponding stub can be gener- 
ated because of the absence of a corresponding RMI 
compiler, the control section 62 sends a notification rep- 
resenting it to the stub search interface 27. 
[0074] The RMI processing procedure of this embod- 
iment will be described next with reference to the flow 
chart shown in Fig. 7. The same reference numerals as 
in Fig. 4 denote the same steps in Fig. 7. 
[0075] In this embodiment, when it is determined by 
stub class search by the stub search interface 27 that 
no corresponding stub class is present in the stub class- 
es 26-1 to 26-3 (NO in step S10), the stub class name 
and client identifier are sent from the stub search inter- 
face 27 to activate the stub generation section 30. The 
control section 62 of the stub generation section 30 de- 
termines whether an interface class corresponding to 
the stub class name is present in the interface classes 

60- 1 to 60-m and whether an RMI compiler correspond- 
ing to the client identifier is present in the RM I compilers 

61- 1 to 61 -n, thereby checking whether the requested 
stub class can be generated (step S21). 
[0076] If YES in step S21, the corresponding stub 
class is dynamically generated under the control by the 
control section 62 of the stub generation section 30, and 
the generated stub class is returned to the stub search 
interface 27 (step S22). The stub search interface 27 
returns the stub class to the client computer 1 , 2, or 3 
of the request source and stores the stub class in the 
storage section 29 (step S11). 

[0077] If NO in step S21 , a message representing it 
is returned from the stub generation section 30 to the 
stub search interface 27, and the stub search interface 



27 sends a notification representing that no correspond- 
ing stub class is present to the client computer 1 , 2, or 
3 of the request source (step S12). 
[0078] According to this embodiment, stub classes 
that can be used for remote method invocation in the 
client computers 1 to 3 are dynamically generated, as 
needed, and downloaded from the single server com- 
puter 4 to the plurality of client computers 1 to 3 having 
different types of Java runtime environments. This 
makes it possible to execute remote method invocation 
for the method of the same server object. For this rea- 
son, the server computer need to have only one service 
having the same inlet for the client computers 1 to 3 with 
different configurations. In addition, stub classes corre- 
sponding to all configurations need not be prepared in 
the server computer 4 in advance. 
[0079] In this embodiment, the servercomputer 4 may 
be activated in a state wherein no stub classes are 
stored in the storage section 29 at all. Alternatively, 
some stub classes may be stored in the storage section 
29 in advance at the time of activation of the servercom- 
puter 4, as in the first embodiment. In addition, a stub 
class generated by the stub generation section 30 is 
stored in the storage section 29 in the above decryption, 
though the stub class need not always be stored. 
[0080] Fig. 8 shows a computer system according to 
the third embodiment of the present invention. The 
same reference numerals as in Fig. 5 denote the same 
parts in Fig. 8. The third embodiment is different from 
the second embodiment shown in Fig. 5 in that a server 
computer 4 does not hold the sets of stub classes, and 
all stub classes download-requested from client com- 
puters 1 to 3 are dynamically generated. Forthis reason, 
a storage section 29 for stub classes 26-1 to 26-3 are 
omitted. 

[0081 ] Upon receiving a stub request with a designat- 
ed stub class name and client identifier from one of the 
client computers 1 to 3, a stub search interface 27 noti- 
fies a stub generation section 30 of the stub class name 
and client identifier to instruct the stub generation sec- 
tion 30 to generate a stub class. The stub generation 
section 30 generates the stub class according to the 
same procedure described with reference to Fig. 5 and 
returns the stub class to the stub search interface 27. 
The stub search interface 27 sends the stub class to the 
client computer 1, 2, or 3 of the request source. If the 
stub generation section 30 cannot generate a corre- 
sponding stub class, the stub search interface 27 sends 
a notification representing that no stub class is found to 
the client computer 1 , 2, or 3 of the request source. 
[0082] RMI processing of this embodiment will be de- 
scribed next with reference to the flow chart shown in 
Fig. 9. The same reference numerals as in Fig. 7 denote 
the same steps in Fig. 9. In this embodiment, when a 
stub request is received from the client computer, the 
stub generation section 30 is immediately activated from 
the stub search interface 27, and the stub generation 
section 30 checks whether it can generate a stub class 
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(step S21). 

[0083] If YES in step S21 , the stub generation section 
30 generates a corresponding stub class and transfers 
it to the stub search interface 27 (step S22). The stub 
search interface 27 returns the stub class to the client 
computer 1 , 2, or 3 of the request source (step S11). If 
NO in step S21 , a notification representing it is sent from 
the stub generation section 30 to the stub search inter- 
face 27. The stub search interface 27 sends a notifica- 
tion representing that no corresponding stub class is 
present to the client computer 1 , 2, or 3 of the request 
source (step S12). 

[0084] According to this embodiment, stub classes 
that can be used for remote method invocation in the 
client computers 1 to 3 are dynamically generated and 
downloaded from the single server computer 4 to the 
plurality of client computers 1 to 3 having different types 
of Java runtime environments. This makes it possible to 
execute remote method invocation for the method of the 
same server object. For this reason, the server compu- 
ter need have only one service having the same inlet for 
the client computers 1 to 3 with different configurations. 
In addition, stub classes need not be prepared in the 
server computer 4. 

[0085] A stub may be prepared on the server side for 
each of clients having difference runtime environments, 
and a stub generation section for generating a stub for 
each of clients having different runtime environments 
may be prepared on the server side. In this case, in 
transmitting a stub request from a client to the server, a 
client identifier capable of specifying the runtime envi- 
ronment of the client is transmitted in addition to the stub 
name. On the server side, an appropriate stub is 
searched for on the basis of the designated stub name 
and client identifier and returned to the client of the re- 
quest source. If no appropriate stub is present, a stub 
appropriate for the runtime environment of the client 
having the designated client identifier is generated and 
returned to the client of the request source. With this 
arrangement, an appropriate stub can be downloaded 
from a single server computer to each of a plurality of 
client computers having runtime environments of differ- 
ent types. 

[0086] As has been described above, according to the 
present invention, an appropriate stub can be down- 
loaded from a single server computer to each of a plu- 
rality of client computers having different types of runt- 
ime environments. In the arrangement for dynamically 
generating a stub by the stub generation section, stubs 
corresponding to all configurations need not be pre- 
pared on the server side in advance. 



Claims 

1. A stub search loading system for, in executing re- 
mote method invocation from a plurality of clients (1 
- 3) to a server (4), downloading a stub necessary 



in a request source client from the server, charac- 
terized in that 

the request source client comprises stub 
search means (13) for sending a stub request 
5 formed from a stub name and client identifier to the 
server and receiving a stub returned from the serv- 
er, and 

the server comprises a stub search interface 
(27) for, in response to the stub request from the 
10 request source client, returning to the request 
source client the stub appropriate for a runtime en- 
vironment of the request source client on the basis 
of the designated stub name and client identifier. 

15 2. A system according to claim 1 , wherein 

the server further comprises a stub set (26-1 
- 26-3) in which a stub to be used together with a 
skeleton used in the server at the time of remote 
method invocation from the request source client is 

20 prepared for each of types of the clients having dif- 
ferent runtime environments, and 

upon receiving the stub request from the re- 
quest source client, said stub search interface 
searches said stub set for the corresponding stub 

25 on the basis of the designated stub name and client 
identifier and returns the stub to the request source 
client. 

3. A system according to claim 1 , wherein 

30 the server further comprises stub generation 

means (30) for generating, for each of types of the 
clients having different runtime environments, a 
stub to be used together with a skeleton used in the 
server at the time of remote method invocation from 

35 the request source client, and 

upon receiving the stub request from the cli- 
ent, said stub search interface returns to the request 
source client the stub appropriate for the runtime 
environment of the request source client, which is 

40 generated by said stub generation means on the 
basis of the designated stub name and client iden- 
tifier. 

4. A system according to claim 2, wherein 

45 the server further comprises stub generation 

means (30) for generating, for each of types of the 
clients having different runtime environments, a 
stub to be used together with a skeleton used in the 
server at the time of remote method invocation from 

so the client, and 

when the corresponding stub is not present in 
said stub set, said stub search interface returns to 
the request source client the stub appropriate for 
the runtime environment of the request source cli- 

55 ent, which is generated by said stub generation 
means on the basis of the designated stub name 
and client identifier. 
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5. A stub search loading method of, in executing re- 
mote method invocation from a plurality of clients (1 
- 3) to a server (4), downloading a stub necessary 
in a request source client from the server, charac- 
terized by comprising the steps of: s 

sending a stub request formed from a stub 
name and client identifier from the request 
source client to the server; 

upon receiving the stub request, returning from 10 
the server to the request source client a stub to 
be used together with a skeleton used in the 
server at the time of remote method invocation 
from the request source client, on the basis of 
the designated stub name and client identifier; is 
and 

receiving, at the request source client, the stub 
transmitted from the server. 

6. A method according to claim 5, wherein the return 20 
step comprises the steps of 

in the server on the basis of the designated 
client identifier, selecting one of stub sets (26-1 - 
26-3) in which a stub to be used together with a skel- 
eton used in the server at the time of remote method 25 
invocation from the request source client is pre- 
pared for each of types of the clients having different 
runtime environments, 

selecting the stub having the designated stub 
name from the selected stub set, and 30 

transmitting the selected stub from the server 
to the request source client. 

7. A method according to claim 5, wherein the return 
step comprises the steps of 35 

in the server on the basis of the designated 
stub name and client identifier, generating a stub to 
be used together with a skeleton used in the server 
at the time of remote method invocation from the 
request source client, and *o 

transmitting the generated stub from the serv- 
er to the request source client. 

8. A method according to claim 6, wherein the return 
step comprises the steps of *s 

in the server, when a stub cannot be selected 
from the stub set, generating a stub to be used to- 
gether with a skeleton used in the server at the time 
of remote method invocation from the request 
source client on the basis of the designated stub so 
name and client identifier, and 

transmitting the generated stub from the serv- 
er to the request source client. 

9. A server apparatus for providing a stub necessary ss 
in executing remote method invocation to a request 
source client in response to a stub request from the 
client, characterized by comprising: 
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a stub search interface (27) for, in response to 
the stub request from the request source client, 
returning to the request source client the stub 
appropriate for a runtime environment of the re- 
quest source client on the basis of the desig- 
nated stub name and client identifier. 

10. An apparatus according to claim 9, wherein 

said apparatus further comprises a stub set 
(26-1 - 26-3) in which a stub to be used together 
with a skeleton used at the time of remote method 
invocation from the request source client is pre- 
pared for each of types of clients having different 
runtime environments, including the request source 
client, and 

upon receiving from the request source client 
the stub request formed from the stub name and 
client identifier, said stub search interface searches 
said stub set for the appropriate stub on the basis 
of the designated stub name and client identifier 
and returns the stub to the request source client. 

11. An apparatus according to claim 9, wherein 

said apparatus further comprises stub gener- 
ation means (30) for generating, for each of types 
of clients having different runtime environments, in- 
cluding the request source client, a stub to be used 
together with a skeleton used at the time of remote 
method invocation from the request source client, 
and 

upon receiving the stub request from the cli- 
ent, said stub search interface returns to the request 
source client the stub appropriate for the runtime 
environment of the request source client, which is 
generated by said stub generation means on the 
basis of the designated stub name and client iden- 
tifier. 

12. An apparatus according to claim 10, wherein 

said apparatus further comprises stub gener- 
ation means (30) for generating, for each of types 
of clients having different runtime environments, in- 
cluding the request source client, a stub to be used 
together with a skeleton used at the time of remote 
method invocation from the client, and 

when the corresponding stub is not present in 
said stub set, said stub search interface returns to 
the request source client the stub appropriate for 
the runtime environment of the request source cli- 
ent, which is generated by said stub generation 
means on the basis of the designated stub name 
and client identifier. 

13. A client apparatus for downloading a stub neces- 
sary in a client in executing remote method invoca- 
tion from a server (4), characterized by compris- 
ing: 
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stub search means (13) for transmitting a stub 
request formed from a stub name and client 
identifier to a server having a stub search inter- 
face for, in response to the stub request from 
the client, returning to the request source client 5 
the stub appropriate for a runtime environment 
of the request source client on the basis of the 
designated stub name and client identifier, and 
receiving the stub returned from the server ap- 
paratus in response to the stub request. io 

14. An apparatus according to claim 13, wherein 

said apparatus further comprises a stub set 
(26-1 - 26-3) in which a stub to be used together 
with a skeleton used in the server apparatus at the is 
time of remote method invocation from the request 
source client is prepared for each of types of clients 
having different runtime environments, including 
the request source client, and 

upon receiving from the request source client 20 
the stub request formed from the stub name and 
client identifier, the stub search interface searches 
said stub set for the appropriate stub on the basis 
of the designated stub name and client identifier 
and returns the stub to the request source client. 25 

15. An apparatus according to claim 13, wherein 

said apparatus further comprises stub gener- 
ation means (30) for generating, for each of types 
of clients having different runtime environments, in- 30 
eluding the request source client, a stub to be used 
together with a skeleton used in the server appara- 
tus at the time of remote method invocation from 
the request source client, and 

upon receiving the stub request from the cli- 35 
ent, the stub search interface returns to the request 
source client the stub appropriate for the runtime 
environment of the request source client, which is 
generated by said stub generation means on the 
basis of the designated stub name and client iden- 40 
tifier. 

16. An apparatus according to claim 14, wherein 

said apparatus further comprises stub gener- 
ation means (30) for generating, for each of types 45 
of clients having different runtime environments a 
stub to be used together with a skeleton used in the 
server apparatus at the time of remote method in- 
vocation from the client, and 

when the corresponding stub is not present in 50 
said stub set, the stub search interface returns to 
the request source client the stub appropriate for 
the runtime environment of the request source cli- 
ent, which is generated by said stub generation 
means on the basis of the designated stub name 55 
and client identifier. 

17. A computer-readable recording medium which 



stores a program for executing stub search loading 
processing of , in executing remote method invoca- 
tion from a plurality of clients (1 - 3) to a server (4), 
downloading a stub necessary in a request source 
client from the server, characterized in that the 
program comprises: 

a procedure code for sending a stub request 
formed from a stub name and client identifier 
from the request source client to the server; 
a procedure code for, upon receiving the stub 
request, returning from the server to the re- 
quest source client a stub to be used together 
with a skeleton used in the server at the time of 
remote method invocation from the request 
source client, on the basis of the designated 
stub name and client identifier; and 
a procedure code for receiving, at the request 
source client, the stub transmitted from the 
server. 

18. A medium according to claim 17, wherein the pro- 
gram for executing the procedure code for returning 
comprises 

a procedure code for, in the server on the ba- 
sis of the designated client identifier, selecting one 
of stub sets (26-1 - 26-3) in which a stub to be used 
together with a skeleton used in the server at the 
time of remote method invocation from the request 
source client is prepared for each of types of the 
clients having different runtime environments, 

a procedure codefor selecting thestub having 
the designated stub name from the selected stub 
set, and 

a procedure code for transmitting the selected 
stub from the server to the request source client. 

19. A medium according to claim 17, wherein the pro- 
gram for executing the procedure code for returning 
comprises 

a procedure code for, in the server on the ba- 
sis of the designated stub name and client identifier, 
generating a stub to be used together with a skele- 
ton used in the server at the time of remote method 
invocation from the request source client, and 

a procedure code for transmitting the gener- 
ated stub from the server to the request source cli- 
ent. 

20. A medium according to claim 18, wherein the pro- 
gram for executing the procedure code for returning 
comprises 

a procedure code for, in the server, when a 
stub cannot be selected from the stub set, generat- 
ing a stub to be used together with a skeleton used 
in the server at the time of remote method invoca- 
tion from the request source client on the basis of 
the designated stub name and client identifier, and 
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a procedure code for transmitting the gener- 
ated stub from the server to the request source cli- 
ent. 

21. A computer-readable recording medium which s 
stores a program for executing processing of pro- 
viding a stub necessary in executing remote meth- 
od invocation to a request source client in response 

to a stub request from the client, characterized in 
that the program comprises: 10 

a procedure code for, in response to the stub 
request from the request source client, return- 
ing to the request source client the stub appro- 
priate for a runtime environment of the request *s 
source client on the basis of the designated 
stub name and client identifier. 

22. A medium according to claim 21 , wherein the pro- 
gram for executing the procedure code for returning 20 
comprises 

a procedure code for, in the server on the ba- 
sis of the designated client identifier, selecting one 
of stub sets (26-1 - 26-3) in which a stub to be used 
together with a skeleton used in the server at the 25 
time of remote method invocation from the request 
source client is prepared for each of types of the 
clients having different runtime environments, 

a procedure code for selecting the stub having 
the designated stub name from the selected stub 30 
set, and 

a procedure code fortransmitting the selected 
stub from the server to the request source client. 

23. A medium according to claim 21 , wherein the pro- 35 
gram for executing the procedure code for returning 
comprises 

a procedure code for, in the server on the ba- 
sis of the designated stub name and client identifier, 
generating a stub to be used together with a skele- *o 
ton used in the server at the time of remote method 
invocation from the request source client, and 

a procedure code for transmitting the gener- 
ated stub from the server to the request source cli- 
ent. 45 

24. A medium according to claim 22, wherein the pro- 
gram for executing the procedure code for returning 
comprises 

a procedure code for, in the server, when a so 
stub cannot be selected from the stub set, generat- 
ing a stub to be used together with a skeleton used 
in the server at the time of remote method invoca- 
tion from the request source client on the basis of 
the designated stub name and client identifier, and 55 

a procedure code for transmitting the gener- 
ated stub from the server to the request source cli- 
ent. 
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